New LXX in an existing primary/shadow MUF
search cancel

New LXX in an existing primary/shadow MUF

book

Article ID: 429222

calendar_today

Updated On:

Products

Datacom Datacom/AD Datacom/DB

Issue/Introduction

Can we transition to a new bigger LXX in a primary / shadow configuration without taking an outage?
If yes, what do I need to do?

Cause

Planning to enable inactive recovery in busiest MUF. The current LXX is too small, and it's not feasible to extend dynamically once we enable inactive recovery given the primary & secondary allocations. We want to define and INIT a new LXX beforehand, and transition to the new LXX during a maintenance window when we enable inactive recovery. The following steps were done in a sandbox environment:

1. Created and initialized a new LXX with suffix of .NEW.
2. Updated SHADOW MUF, started task JCL, and renamed the LXX to .NEW.
3. Cycled SHADOW MUF and came up in shadow mode with the new name. That worked fine.
4. Updated PRIMARY MUF, started task JCL with the LXX as .NEW.
5 Cancelled PRIMARY MUF to failover. SHADOW MUF abended when it attempted to take over.
6. Since both primary & shadow were down, tried bringing up PRIMARY MUF with the new LXX and inactive recovery enabled. It also failed.
7. Backed out all changes until I could analyze what went wrong, and restarted PRIMARY MUF with the original LXX and inactive recover off which worked fine.
10. Restarted SHADOW MUF in shadow mode without issues

RESULTS: The SHADOW MUF got a series of RC46 errors before abending with an SVC dump. The PRIMARY MUF did the same. Both were pointing to the new LXX.

Resolution

No, the primary and shadow MUF share the same LXX. Therefore, it can't be done without a MUF outage.

The only way without a MUF outage, is to do a DYNAMIC_EXTEND of the LXX. The shadow MUF needs to be terminated before doing the DYNAMIC_EXTEND.

Additional Information

Considerations for extending the log area LXX.